1. Field of the Invention
The present invention relates to the field of circuit design and, more particularly, to incremental implementation flow for programmable logic devices.
2. Description of the Related Art
Incremental Implementation Flow (incremental flow) refers to a methodology for processing circuit designs in a manner that attempts to reuse prior implementation results for unchanging portions of the design. Incremental flow typically is used when an incremental change is made to a circuit design intended for use on a target programmable logic device (PLD), such as a field programmable gate array (FPGA). In general, an incremental change can be one that affects one or more portions of the circuit design. Typically, an incremental change neither significantly alters the size of the circuit design nor adversely affects the timing of the circuit design as a whole. Still, an incremental change can be more substantive in that timing may be adversely affected. Examples of incremental design changes can include, but are not limited to, changes to state machines, control logic, or the addition of registers intended to improve performance of the circuit design.
Incremental flow provides several benefits, making it a useful and desirable circuit design technique. One such benefit is that achieving verified results can be accomplished more rapidly. Results from a prior implementation flow likely have undergone significant testing and/or verification. In depth analysis of this sort is critical to ensuring a reliable circuit design. Repeating such analysis each time the circuit design undergoes a minor, or incremental, change can be cumbersome and time consuming, particularly since significant portions of the circuit design remain unchanged. Re-use of previously tested portions of the circuit design can reduce the time needed to arrive at a verified design solution.
Another benefit is that incremental flow supports a “divide and conquer” approach to circuit design. Creating a circuit design that conforms to an established design goal, for example in terms of timing requirements, power consumption, and the like, can be exceedingly difficult and time consuming. In such cases, it is useful to “lock” one or more particularly complex or troublesome portions of the circuit design to prevent further changes to those portions as other sections of the circuit design continue to evolve. The designer can direct his or her attention to the unfinished, evolving portions of the circuit design.
Incremental flow, however, is not without its disadvantages. In performing incremental flow, it often is necessary for multiple software applications to access the same store of dependency management data. Dependency management data can include implementation data from the various phases of incremental flow. When an incremental flow is performed, it often is the case that a different software-based implementation tool is used to perform each phase, i.e. synthesis, translation, mapping, packing, placement, and routing. To perform its allotted task, each implementation tool must access the dependency management data. Typically, each implementation tool includes its own interface for accessing the dependency management data. This can lead to a situation in which a designer must deal with a plurality of different programming interfaces for accessing and dealing with the dependency management data within the context of a single incremental flow.
Another disadvantage is that the individual implementation tools executed during each phase of an incremental flow usually work with dependency management data on a per circuit design basis. That is, if any part of the circuit design, i.e. a particular file of the circuit design project, is out-of-date, the entire circuit design is considered to be out-of-date necessitating re-implementation of the entire circuit design. Other implementation tools are configured to assume, at startup, that the circuit design is out-of-date, and thus, re-implement the entire circuit design.
In other cases, implementation tools attempt to determine which portions of the circuit design must be re-implemented for a given phase of incremental flow. Such tools, however, process the entire design, compare the implementation results with the previous run, and make a determination as to whether the results are the same. This approach is inefficient as the work of implementation is performed prior to the determination of whether portions of the circuit design have been changed and require re-implementation. Further, on some occasions consecutive runs of an implementation tool do not produce the same results. This situation depends upon the precision of the implementation algorithms used by the implementation tool. In such cases, the implementation tool may indicate that a change has been made to a portion of the circuit design since the implementation result differs from a prior run, when in fact the designer made no change.
It would be beneficial to provide a technique for managing and/or accessing dependency management data for incremental flow which addresses the limitations described above.